[レポート] 生成AIアプリにおけるインシデント対応のセッション – 生成AIワークロードにおける脅威の検出と対応 #TDR302 #AWSreInforce

あしざわです。

米国フィラデルフィアで開催されている AWS re:Inforce 2024 に参加しています。

本記事は AWS re:Inforce 2024 の Breakout Session 「Detecting and responding to threats in generative AI workloads」のレポートです。

セッション概要

While generative AI is an emerging technology, many of the same services and concepts can be used for threat detection and incident response. In this session, learn how you can build out threat detection and incident response capabilities for a generative AI workload that uses Amazon Bedrock. Find out how to effectively monitor this workload using Amazon Bedrock, Amazon GuardDuty, and AWS Security Hub. The session also covers best practices for responding to and remediating security issues that may come up.

セッションの詳細

生成AIの活用とは、活用レイヤーで分けて以下の3パターンに分類できる

• Amazon QのようなLLM(大規模言語モデル)、FM(基盤モデル)を活用したアプリケーションを利用する
• Amazon Bedrockなどを使ったLLMやFMを利用したツールを作成する
• GPUなどを使ってFMのインフラから管理する

それぞれのパターンごとにAWS責任共有モデルも異なり、よりカスタマイズ性が高いとユーザーの責任範囲が大きく、カスタマイズ性が低いと責任範囲は小さい。

※左から、インフラ管理、ツール作成、アプリケーション利用の責任共有モデル

AI/MLアプリケーションのコンポーネントは以下のように分類できる

• 組織
  • アプリケーションのアクセスできる機関や企業
• コンピューティング・インフラリソース
  • EC2、RDSなどのアプリケーションを動作させるもの
• AL/MLアプリケーション
  • AI/MLモデル、トレーニングデータ、ナレッジベース、エージェントなど
• プライベートデータ
  • 個人情報などの機密情報
• ユーザー
  • 認証されたユーザー、認証されていないユーザー

各コンポーネントが相互作用する要素とセキュリティインシデント発生時に意識するべき点は以下

• アクセス
  • 自信がアプリケーションにまだアクセスできるか（ロックアウトされていないか）
  • アカウント内での不正アクティビティが継続的に行われている証拠があるか
• コンピューティングの変更
  • どのようなリソースが変更・削除されてしまったか
• AIモデルの変更
  • FMのカスタムモデルや、特にガードレールが変更されていないか
• データストアの変更
  • データストアやナレッジベースの変更権限を持っているか
• モデルの呼び出し
  • AI/MLワークロードはプロンプトとレスポンスで動作するため、とても重要
• プライベートデータ
  • ユースケースによってはAI/MLアプリを個人情報にアクセスさせる場合もある点は注意（ただし一般的に機密情報にアクセスさせるべきではない）
• プロキシ
  • コンポーネントに対する変更を行ったユーザーは認証されたユーザーか、不正な変更か

セキュリティインシデントが起きた際、基本的にはまずCloudTrailのイベントを確認し攻撃された痕跡を追いかけます。

• 例
  • アクセス：Attach UserPolicy、CreateAccessKey、 ConsoleLoginなどの認証情報関連
  • コンピュートリソースへの変更：RunInstances、DeleteDBInstanceなどのインフラ変更
  • AIMLモデルの変更：CreateCustomModel、DeleteCustomModelなど
  • など...

こういったインシデント対応がどのようにしたら実用的になるのか？一般的なインシデントレスポンスのフレームワークに則って解説します。

まずはPreperation(準備)です。AI/MLワークロードのインシデントレスポンス/SOCの訓練をしたり、プレイブックの新規作成を行います。

特に重要なのがAI/MLのプロンプト、呼び出し(Invocation)のロギングです。これらのロギングは要するにAI/MLに関する呼び出しのデータイベントを記録することになるため、CloudTrail管理イベントと比べると情報量が多く、インシデント対応時に役立ちます。Amazon BedrockのInvocationログはデフォルトでは有効化されていないため、明示的に有効化することがとても重要です。

続いて、Detection(検知) & Analysys(分析)です。

ここでもBedrockモデルの呼び出し(Invocation)ログの監視が特に強調されていました。GuardDutyの重要性はクレデンシャルの漏洩という点では他のワークロードと同じ、Security HubやConfigの文脈ではデータの暗号化が重要です。

続いては、Contaiment(封じ込め)、Eradication(根絶)、Recovery(復旧)です。

封じ込めの例としてシステムをオフラインにしたり、アクセス権を剥奪します。根絶では汚染されたトレーニングデータの除去や認証情報の削除、復旧はシステムやワークロードを元の状態に戻すことです。これらの対応パターンはワークロードによって無数にあるため、一覧化が難しいです。

最後はインシデントから学ぶこと(Past-Incident Activity)です。

特別なことではなく、過去のインシデントを振り返って組織を改めることが大切です。

最後にまとめのスライドです。

インシデントレスポンスの基礎ができていること、AL/MLワークロードの理解、ワークロードにある機密情報の把握、IAM最小権限など一般的なワークロードと近いところも多いです。

AI/MLワークロードの特徴は先述したInvocationログのようなデータイベントの記録が大事、というものが他のワークロードとの差です。

まとめ

以上、「Detecting and responding to threats in generative AI workloads」のレポートでした。

AI/MLワークロードのセキュリティインシデント発生時のチェックポイントがよく理解できました。Invocationログのようなデータイベントの取得が重要になってくる点が、他と違うためここは是非とも押さえておきたいポイントですね。

以上です。